Reviewing files that changed from the base of the PR and between 4a867cf and 4c8a508.

• backend/app_tests/api/test_api_compliance_assessments.py (12 hunks)
• backend/app_tests/api/test_api_perimeters.py (1 hunks)
• backend/app_tests/api/test_api_projects.py (0 hunks)
• backend/app_tests/api/test_api_requirement_assessments.py (6 hunks)
• backend/app_tests/api/test_api_risk_acceptances.py (3 hunks)
• backend/app_tests/api/test_api_risk_assessments.py (15 hunks)
• backend/app_tests/api/test_api_risk_scenarios.py (9 hunks)
• backend/app_tests/test_vars.py (1 hunks)
• backend/core/base_models.py (1 hunks)
• backend/core/filters.py (5 hunks)
• backend/core/helpers.py (9 hunks)
• backend/core/locale/fr/LC_MESSAGES/django.po (3 hunks)
• backend/core/management/commands/status.py (2 hunks)
• backend/core/migrations/0050_rename_project_perimeter_alter_perimeter_options_and_more.py (1 hunks)
• backend/core/models.py (10 hunks)
• backend/core/serializers.py (9 hunks)
• backend/core/startup.py (11 hunks)
• backend/core/templates/core/action_plan_pdf.html (1 hunks)
• backend/core/templates/snippets/mp_data.html (1 hunks)
• backend/core/templates/snippets/ra_data.html (1 hunks)
• backend/core/tests/fixtures.py (2 hunks)
• backend/core/tests/test_helpers.py (2 hunks)
• backend/core/tests/test_models.py (35 hunks)
• backend/core/tests/test_requirement_assessment.py (3 hunks)
• backend/core/tests/test_vulnerability.py (4 hunks)
• backend/core/urls.py (1 hunks)
• backend/core/views.py (12 hunks)
• backend/ebios_rm/serializers.py (1 hunks)
• backend/iam/models.py (1 hunks)
• backend/iam/tests/test_user.py (5 hunks)
• backend/serdes/tests/test_dump.py (1 hunks)
• backend/serdes/utils.py (8 hunks)
• backend/tprm/migrations/0004_remove_entityassessment_project_and_more.py (1 hunks)
• backend/tprm/serializers.py (2 hunks)
• backend/tprm/views.py (1 hunks)
• cli/clica.py (4 hunks)
• enterprise/frontend/src/lib/components/SideBar/navData.ts (6 hunks)
• frontend/messages/ar.json (6 hunks)
• frontend/messages/cs.json (6 hunks)
• frontend/messages/de.json (6 hunks)
• frontend/messages/en.json (9 hunks)
• frontend/messages/es.json (6 hunks)
• frontend/messages/fr.json (7 hunks)
• frontend/messages/hi.json (6 hunks)
• frontend/messages/id.json (6 hunks)
• frontend/messages/it.json (6 hunks)
• frontend/messages/nl.json (8 hunks)
• frontend/messages/pl.json (6 hunks)
• frontend/messages/pt.json (6 hunks)
• frontend/messages/ro.json (6 hunks)
• frontend/messages/sv.json (6 hunks)
• frontend/messages/ur.json (6 hunks)
• frontend/src/lib/components/DetailView/DetailView.svelte (1 hunks)
• frontend/src/lib/components/Forms/ModelForm.svelte (2 hunks)
• frontend/src/lib/components/Forms/ModelForm/ComplianceAssessmentForm.svelte (1 hunks)
• frontend/src/lib/components/Forms/ModelForm/EntityAssessmentForm.svelte (1 hunks)
• frontend/src/lib/components/Forms/ModelForm/RiskAcceptanceForm.svelte (1 hunks)
• frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte (1 hunks)
• frontend/src/lib/components/Forms/ModelForm/RiskScenarioForm.svelte (1 hunks)
• frontend/src/lib/components/SideBar/SideBar.svelte (1 hunks)
• frontend/src/lib/components/SideBar/navData.ts (3 hunks)
• frontend/src/lib/utils/crud.ts (7 hunks)
• frontend/src/lib/utils/schemas.ts (5 hunks)
• frontend/src/lib/utils/table.ts (7 hunks)
• frontend/src/lib/utils/types.ts (2 hunks)
• frontend/src/routes/(app)/(internal)/[model=urlmodel]/[id=uuid]/+page.server.ts (1 hunks)
• frontend/src/routes/(app)/(internal)/analytics/+page.server.ts (2 hunks)
• frontend/src/routes/(app)/(internal)/analytics/+page.svelte (2 hunks)
• frontend/src/routes/(app)/(internal)/analytics/ComposerSelect.svelte (1 hunks)
• frontend/src/routes/(app)/(internal)/analytics/composer/+page.svelte (1 hunks)
• frontend/src/routes/(app)/(internal)/compliance-assessments/[id=uuid]/action-plan/+page.svelte (1 hunks)
• frontend/src/routes/(app)/(internal)/recap/+page.server.ts (6 hunks)
• frontend/src/routes/(app)/(internal)/recap/+page.svelte (2 hunks)
• frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/+page.svelte (1 hunks)
• frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/remediation-plan/+page.svelte (1 hunks)
• frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/+page.svelte (1 hunks)
• frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/edit/+page.server.ts (1 hunks)
• frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/edit/+page.svelte (1 hunks)
• frontend/src/routes/(app)/(internal)/x-rays/+page.server.ts (1 hunks)
• frontend/src/routes/(app)/(internal)/x-rays/+page.svelte (4 hunks)
• frontend/src/routes/(app)/(third-party)/compliance-assessments/[id=uuid]/+page.svelte (1 hunks)
• frontend/tests/functional/detailed/common.test.ts (2 hunks)
• frontend/tests/functional/detailed/compliance-assessments.test.ts (1 hunks)
• frontend/tests/functional/user-route.test.ts (5 hunks)
• frontend/tests/utils/page-detail.ts (1 hunks)
• frontend/tests/utils/test-data.ts (11 hunks)
• frontend/tests/utils/test-utils.ts (11 hunks)

• backend/app_tests/api/test_api_projects.py

• GitHub Check: startup-docker-compose-test
• GitHub Check: functional-tests (3.12, chromium)
• GitHub Check: build (3.12)
• GitHub Check: enterprise-startup-docker-compose-test
• GitHub Check: test (3.12)
• GitHub Check: enterprise-functional-tests (3.12, chromium)

frontend/messages/nl.json (5)

28-28: Basic term translations look good!

The translations for "perimeter" related terms are consistent and correctly follow Dutch language rules.

Also applies to: 41-41, 81-81

---

119-119: Single term translation is correct!

The technical term "perimeter" is appropriately kept as-is in the Dutch translation.

---

187-187: UI text translations with variable interpolation are correct!

The translations maintain proper Dutch grammar and correctly preserve the variable interpolation.

Also applies to: 189-189

---

224-224: Summary text translation is accurate!

The empty state message is correctly translated and follows the same pattern as other similar messages in the file.

---

756-756: Error message translation is well-formed!

The translation maintains a formal tone and correctly uses Dutch technical terminology.

frontend/src/lib/utils/crud.ts (9)

155-155: Good job on renaming the reverseForeignKeyFields.

This change is consistent with the updated perimeter-centric architecture.

---

159-170: New perimeters entry looks coherent.

The fields and naming convention align well with the perimeter-based model. No concerns regarding consistency or readability.

---

193-193: Renaming the foreign key reference to perimeter is correct.

This aligns with the perimeter refactor.

---

210-210: Foreign key fields renamed to perimeter.

This matches the new model structure and fosters consistency.

---

235-235: Foreign key field referencing perimeters is correct.

No issues found.

---

468-468: Compliance-assessments referencing perimeters.

This ensures consistent naming and avoids confusion.

---

563-563: Entity-assessments pointing to perimeter.

Rename is uniform across the codebase.

---

880-880: New perimeters entry in FIELD_COLORED_TAG_MAP.

All references align with perimeter-based model. The color mapping seems straightforward.

---

202-202: Filters updated to include perimeter.

Ensure any code referencing the old project filter key has been updated accordingly.

backend/core/serializers.py (10)

214-219: PerimeterReadSerializer logic looks sound.

Including folder and lc_status ensures completeness of perimeter data retrieval.

🧰 Tools

🪛 Ruff (0.8.2)

219-219: Perimeter may be undefined, or defined from star imports

(F405)

---

223-227: PerimeterImportExportSerializer properly reflects the perimeter design.

Looks consistent with the existing serializer patterns.

🧰 Tools

🪛 Ruff (0.8.2)

227-227: Perimeter may be undefined, or defined from star imports

(F405)

---

248-248: Field list updated to include perimeter.

Change is consistent with the perimeter refactor in RiskAssessmentDuplicateSerializer.

---

253-253: Replacing project with perimeter in RiskAssessmentReadSerializer.

Ensures references match the new data model.

---

Line range hint 269-280: RiskAssessmentImportExportSerializer uses perimeter field.

The slug-based approach for read-only references is maintained. No issues.

---

462-463: RiskScenarioReadSerializer reading from risk_assessment.perimeter.

Field rename is aligned with the rest of the code.

---

864-864: perimeter field in ComplianceAssessmentReadSerializer.

Smooth transition from the old project field.

---

Line range hint 916-926: ComplianceAssessmentImportExportSerializer referencing perimeter.

Renaming is consistent with other import/export serializers.

🧰 Tools

🪛 Ruff (0.8.2)

919-919: ComplianceAssessment may be undefined, or defined from star imports

(F405)

---

208-210: Introduced PerimeterWriteSerializer.

Static analysis warns that Perimeter may be from a star import. Confirm that Perimeter is defined in core.models.

✅ Verification successful

Star import confirmed, consider explicit import

The Perimeter model is correctly defined in core.models.py, but it's currently imported via from core.models import *. Consider replacing the star import with an explicit import for better code maintainability:

from core.models import Perimeter

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verifying that Perimeter is declared in core/models.py
ast-grep --pattern $'class Perimeter($_) {\n  $$$\n}' 

Length of output: 52

---

Script:

#!/bin/bash
# Search for Perimeter class definition
rg "class Perimeter" -A 2

# Check imports in serializers.py
rg "from .* import .*Perimeter" backend/core/serializers.py

# Look specifically in models.py
cat backend/core/models.py | grep -A 5 "class Perimeter"

Length of output: 1729

---

Script:

#!/bin/bash
# Check all imports at the top of serializers.py
rg "^from|^import" backend/core/serializers.py

Length of output: 509

🧰 Tools

🪛 Ruff (0.8.2)

210-210: Perimeter may be undefined, or defined from star imports

(F405)

---

111-111: perimeter field in AssessmentReadSerializer.

Change from project to perimeter is coherent. Confirm that any usage of .project in templates or business logic is updated.

✅ Verification successful

Field change from project to perimeter is properly implemented

The change is coherent across the codebase. The field is consistently defined in the base AssessmentReadSerializer and properly extended in child serializers. No problematic usages of .project were found in the serializer context or related code.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Searching for leftover references to AssessmentReadSerializer.project
rg 'AssessmentReadSerializer' -A 10 | rg '\.project'

Length of output: 52

---

Script:

#!/bin/bash
# Find AssessmentReadSerializer usages with context
echo "=== AssessmentReadSerializer usages ==="
rg -l "AssessmentReadSerializer"

echo -e "\n=== Template files with 'project' ==="
fd -e html -e django-html | xargs rg "project"

echo -e "\n=== Python files with Assessment and project ==="
rg -l "class.*Assessment" | xargs rg "project" -C 3

Length of output: 102428

---

Script:

#!/bin/bash
# Find AssessmentReadSerializer implementation and usage
echo "=== AssessmentReadSerializer implementation ==="
rg -A 10 -B 5 "class AssessmentReadSerializer" 

echo -e "\n=== AssessmentReadSerializer usage ==="
rg "AssessmentReadSerializer\(" -A 3

Length of output: 5343

backend/core/helpers.py (10)

120-122: Renamed to compile_perimeter_for_composer.

Docstring matches the new implementation. This is in line with the perimeter-based refactor.

---

139-139: Filtering by compliance_assessment__perimeter__in=perimeters_list.

Filter logic is correct and consistent with the rename.

---

156-156: requirement_assessments__assessment__perimeter__in=perimeters_list.

Ensures correct composition scope.

---

163-167: Building perimeter_objects array.

Retrieving Perimeter via primary key is aligned with the rest of the flow.

🧰 Tools

🪛 Ruff (0.8.2)

166-166: Perimeter may be undefined, or defined from star imports

(F405)

---

170-170: Returning perimeter_objects in the final dict.

Ensures consumers can process the new perimeter-based data set.

---

Line range hint 740-752: risks_per_perimeter_groups: new perimeter-based grouping.

Filtering by risk_assessment__perimeter__folder=folder is coherent with the new domain/perimeter structure.

---

772-774: Counters for perimeters.

Accurate rename from projects key to perimeters.

🧰 Tools

🪛 Ruff (0.8.2)

774-774: Perimeter may be undefined, or defined from star imports

(F405)

---

807-810: Looping over Perimeter.objects and referencing ComplianceAssessment for each.

Logic cleanly fits the perimeter-based flow.

🧰 Tools

🪛 Ruff (0.8.2)

807-807: Perimeter may be undefined, or defined from star imports

(F405)

---

810-810: ComplianceAssessment may be undefined, or defined from star imports

(F405)

---

1012-1014: Concatenating risk_assessment.perimeter with version.

Properly references the perimeter as a string. No issues found.

---

1183-1190: get_folder_content updated for Perimeter references.

Switched from counting by project to counting by perimeter. Flow is well-aligned with the new model.

Also applies to: 1191-1192, 1196-1196

🧰 Tools

🪛 Ruff (0.8.2)

1183-1183: Perimeter may be undefined, or defined from star imports

(F405)

---

1190-1190: ComplianceAssessment may be undefined, or defined from star imports

(F405)

backend/core/tests/test_models.py (54)

8-8: Thanks for updating the import statement to Perimeter.
This aligns with the perimeter-centric model.

---

105-105: Proper reference of perimeter.
This replacement from project to perimeter is consistent with the rename.

---

111-111: Good assertion for verifying perimeter.
Ensures that the risk assessment references the correct perimeter.

---

128-128: Repeated perimeter creation.
Same suggestion as line 101 to consider a shared fixture or factory.

---

132-132: Correct perimeter usage.
No issues found.

---

146-146: Repeated perimeter creation.
Same remark as line 101.

---

150-150: Perimeter assignment is correct.

---

172-172: Repeated perimeter creation.
Same remark as line 101.

---

176-176: Perimeter assignment is correct.

---

202-202: Repeated perimeter creation.
Same remark as line 101.

---

206-206: Perimeter assignment remains consistent.

---

233-233: Repeated perimeter creation.
Same remark as line 101.

---

237-237: Perimeter assignment is correct.

---

243-243: Renamed test method
Accurately reflects perimeter-based uniqueness.

---

253-253: Repeated perimeter creation.
Same remark as line 101.

---

257-257: Perimeter assignment is correct.

---

264-264: Perimeter assignment outside fixture
Still consistent with rename.

---

278-278: Repeated perimeter creation.
Same remark as line 101.

---

282-282: Perimeter usage is correct.

---

289-289: Perimeter usage is correct.

---

294-294: Renamed test method
Accurately verifies usage across different perimeters.

---

306-306: Repeated perimeter creation.
Same remark as line 101.

---

310-310: Perimeter assignment is consistent.

---

319-319: Assigning perimeter2
Ensures coverage of multiple perimeters in tests.

---

324-324: Renamed test method
Scope now references perimeter instead of project.

---

334-334: Repeated perimeter creation.
Same remark as line 101.

---

338-338: Perimeter assignment is correct.

---

344-344: Perimeter assignment remains consistent.

---

350-350: Perimeter assignment remains consistent.

---

354-354: Creating a second perimeter
Consider reusing a fixture for perimeter creation.

---

358-358: Perimeter assignment referencing perimeter2

---

364-364: Another perimeter2 assignment

---

385-385: Repeated perimeter creation
Same remark as line 101.

---

389-389: Perimeter assignment is correct

---

410-410: Renamed test scenario method
Focuses on 'parent_perimeter' instead of 'parent_project'.

---

415-415: Repeated perimeter creation
Same remark as line 101.

---

419-419: Perimeter assignment is consistent

---

431-433: Great test verifying parent perimeter
Ensures the scenario returns the correct perimeter from parent_perimeter().

---

441-441: Repeated perimeter creation
Same remark as line 101.

---

445-445: Perimeter assignment is consistent

---

471-471: Repeated perimeter creation
Same remark as line 101.

---

475-475: Perimeter assignment

---

502-502: Repeated perimeter creation
Same remark as line 101.

---

506-506: Perimeter usage

---

526-526: Repeated perimeter creation
Same remark as line 101.

---

530-530: Perimeter usage

---

555-555: Perimeter assignment

---

Line range hint 566-566: Updated reference to compliance_assessment.perimeter.folder
This is consistent with perimeter-based architecture.

---

711-711: Repeated perimeter creation
Same remark as line 101.

---

715-715: Perimeter assignment

---

750-750: Repeated perimeter creation
Same remark as line 101.

---

754-754: Perimeter usage

---

794-794: Repeated perimeter creation
Same remark as line 101.

---

798-798: Perimeter usage

backend/core/models.py (11)

1351-1351: Introduction of Perimeter model
This is consistent with the perimeter-based refactor.

---

1373-1373: Updated verbose_name
Accurately reflects the new Perimeter naming.

---

1374-1374: Updated verbose_name_plural
Ensures consistent Django admin display.

---

1879-1879: Renamed property
Replaces 'projects' with 'perimeters' to stay consistent with refactor.

---

1880-1880: Use of set comprehension
Returning distinct perimeters for the AppliedControl.

---

2042-2046: Switched to referencing Perimeter
Replaces the former project-based foreign key with a perimeter-based approach.

---

2085-2085: Folder assignment from perimeter
Ensures the newly introduced perimeter is the folder source.

---

2146-2146: Path display updated
Utilizes perimeter folder path for clarity.

---

2602-2603: New parent_perimeter method
This method cleanly retrieves the associated perimeter from the risk assessment.

---

2605-2605: Short description updated
Reflects the 'Perimeter' label in admin.

---

2706-2706: String representation
Displays perimeter name explicitly with the scenario's name.

backend/core/views.py (13)

246-248: Renaming ProjectViewSet to PerimeterViewSet is consistent.

These lines properly shift the focus from projects to perimeters. The updated docstring clarifies the endpoint’s purpose.

---

262-262: Query usage looks correct.

Filtering by UUIDs via id__in=uuid_list is a straightforward approach.

🧰 Tools

🪛 Ruff (0.8.2)

262-262: Perimeter may be undefined, or defined from star imports

(F405)

---

272-274: Access control logic stays consistent with the perimeter-based approach.

No immediate concerns.

🧰 Tools

🪛 Ruff (0.8.2)

272-272: Perimeter may be undefined, or defined from star imports

(F405)

---

274-274: Perimeter may be undefined, or defined from star imports

(F405)

---

309-309: Perimeter-based access check is consistent.

No issues found.

🧰 Tools

🪛 Ruff (0.8.2)

309-309: Perimeter may be undefined, or defined from star imports

(F405)

---

314-314: Same star import concern for PerimeterReadSerializer.

This is a duplicate of the earlier comment about explicit imports.

🧰 Tools

🪛 Ruff (0.8.2)

314-314: PerimeterReadSerializer may be undefined, or defined from star imports

(F405)

---

345-345: Parameter adjustment for object_type=Perimeter.

Implementation follows the new perimeter model.

🧰 Tools

🪛 Ruff (0.8.2)

345-345: Perimeter may be undefined, or defined from star imports

(F405)

---

347-347: Looping over perimeter objects is valid.

No concerns here.

🧰 Tools

🪛 Ruff (0.8.2)

347-347: Perimeter may be undefined, or defined from star imports

(F405)

---

673-674: Filterset fields updated to perimeter-based attributes.

Looks correct as part of the refactor.

---

1557-1558: Filterset on risk_assessment__perimeter fields.

Shifting from project to perimeter is correct and consistent with the new data model.

---

1973-1973: Docstring updated to reflect domains and perimeters.

This statement clearly describes the new structure.

---

2611-2612: Same concern with .get() on _fields["perimeter"].

A missing or invalid perimeter ID would raise DoesNotExist.

🧰 Tools

🪛 Ruff (0.8.2)

2611-2611: Perimeter may be undefined, or defined from star imports

(F405)

---

3202-3202: Filterset update to perimeter aligns with the new architecture.

No issues here.

---

980-980: Handle .get() for Perimeter.objects.get(...) carefully.

This may raise an exception if the record is not found or if data["perimeter"] is missing. Consider adding error handling or a fallback.

 try:
-    perimeter=Perimeter.objects.get(id=data["perimeter"])
+    perimeter = Perimeter.objects.get(id=data["perimeter"])
 except Perimeter.DoesNotExist:
     return Response({"error": "Invalid perimeter ID"}, status=400)

🧰 Tools

🪛 Ruff (0.8.2)

980-980: Perimeter may be undefined, or defined from star imports

(F405)

frontend/src/routes/(app)/(internal)/x-rays/+page.server.ts (1)

6-6: Endpoint changed from projects to perimeters.

This is consistent with the perimeter-centric refactor.

backend/tprm/migrations/0004_remove_entityassessment_project_and_more.py (3)

1-2: Auto-generated migration header.

No issues. The migration comment is standard.

---

14-17: Removing the project field from EntityAssessment.

Eliminating the field aligns with the new perimeter model. Ensure any data referencing project is handled properly before migration.

---

18-27: Introducing a nullable foreign key to Perimeter.

This replacement is consistent with the shift from project to perimeter. Verify that existing references transition smoothly.

frontend/src/routes/(app)/(internal)/analytics/ComposerSelect.svelte (1)

21-21: LGTM! Change aligns with project → perimeter refactoring

The update to use 'perimeter' instead of 'project' in extra_fields is consistent with the broader refactoring effort.

backend/core/tests/fixtures.py (1)

4-4: LGTM! Test fixture properly updated for perimeter refactoring

The changes to the fixture are consistent with the model refactoring from Project to Perimeter.

Let's verify that all test files using this fixture have been updated:

Also applies to: 13-13, 20-21

✅ Verification successful

Refactoring verification complete - all test files properly updated

The codebase has been thoroughly checked and no remaining references to the old Project model or domain_project_fixture were found in any test files. The refactoring from Project to Perimeter appears to be complete and consistent.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining references to the old fixture name
rg "domain_project_fixture" -l

# Search for any remaining Project model references in test files
rg "from core\.models import .*Project" "backend/**/test*.py"
rg "Project\.objects\." "backend/**/test*.py"

Length of output: 262

---

Script:

#!/bin/bash
# Find test files and search for fixture references
fd "test.*\.py$" backend/ | xargs rg "domain_project_fixture" -l

# Search for Project model references in test files
fd "test.*\.py$" backend/ | xargs rg "from core\.models import .*Project" -A 2
fd "test.*\.py$" backend/ | xargs rg "Project\.objects\." -A 2

# Also check for any direct Project class usage
fd "test.*\.py$" backend/ | xargs rg "\bProject\b" -A 2

Length of output: 268

---

Script:

#!/bin/bash
# Check repository structure
ls -R

# Find all Python files to understand project structure
fd "\.py$"

# Find all test-related files regardless of extension
fd "test"

Length of output: 53085

---

Script:

#!/bin/bash
# Search for Project references in test files
rg -l "Project" backend/*/tests/ backend/app_tests/

# Search specifically for the old fixture name
rg -l "domain_project_fixture" backend/*/tests/ backend/app_tests/

# Check for any Project model imports in test files
rg "from core\.models import.*Project" backend/*/tests/ backend/app_tests/

# Look for Project usage in test files
rg "\bProject\." backend/*/tests/ backend/app_tests/

Length of output: 690

backend/core/migrations/0050_rename_project_perimeter_alter_perimeter_options_and_more.py (2)

15-18: LGTM! Model rename operation is correctly defined

The rename operation from Project to Perimeter is properly structured.

---

31-50: Consider data integrity implications of nullable perimeter field

The new perimeter foreign key fields are defined with null=True, which could lead to orphaned assessments. Consider if this is intentional or if assessments should always be associated with a perimeter.

Let's check if there are any existing assessments that might be affected:

frontend/src/lib/components/Forms/ModelForm/RiskScenarioForm.svelte (1)

43-43: LGTM! Change aligns with project → perimeter refactoring

The update to use 'perimeter' instead of 'project' in extra_fields is consistent with the broader refactoring effort.

frontend/src/lib/components/Forms/ModelForm/RiskAcceptanceForm.svelte (1)

62-62: Verify the impact on existing risk scenarios data.

The change from 'project' to 'perimeter' in extra_fields might affect how existing risk scenarios are displayed and filtered in the UI.

Run this script to check for any orphaned risk scenarios:

✅ Verification successful

The change from 'project' to 'perimeter' in extra_fields is safe

The modification is consistent with the codebase architecture where risk scenarios access perimeter data through their risk assessment relationship. This UI-only change doesn't affect existing data or functionality.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for risk scenarios that might be affected by the project->perimeter transition
ast-grep --pattern 'class RiskScenario {
  $$$
  project = $field
  $$$
}'

Length of output: 76

---

Script:

#!/bin/bash
# Find relevant files
echo "=== Files containing RiskScenario ==="
fd -t f -e py -e js -e svelte . | xargs rg -l "RiskScenario"

echo -e "\n=== Risk Scenario API endpoints ==="
rg -A 3 "risk.*scenario" -g "*.py"

echo -e "\n=== Project/Perimeter field usage ==="
rg "(project|perimeter).*(risk|scenario)" -g "*.{py,js,svelte}"

Length of output: 60165

backend/core/management/commands/status.py (1)

15-15: LGTM! Consistent renaming from projects to perimeters.

The changes maintain consistency with the perimeter-centric refactoring.

Also applies to: 41-41

🧰 Tools

🪛 Ruff (0.8.2)

15-15: Perimeter may be undefined, or defined from star imports

(F405)

backend/tprm/views.py (1)

31-31: Verify API backward compatibility for existing clients.

The change in filter fields from 'project' to 'perimeter' might break existing API clients that use these filters.

Run this script to check for API usage patterns:

✅ Verification successful

API change is properly handled through migrations

The change from 'project' to 'perimeter' is part of a planned database schema migration (migration 0050). No direct usage of these filter fields was found in frontend code, and the change is properly handled through Django's migration system, ensuring database consistency.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Search for API calls using project filters
rg -l 'project(?:__folder)?' --type js --type py

Length of output: 1054

---

Script:

#!/bin/bash
# Check when TPRM feature was introduced and the timeline of changes
git log --oneline -- backend/tprm/

Length of output: 0

frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/remediation-plan/+page.svelte (1)

50-50: LGTM! Perimeter references are correctly updated.

The changes consistently replace project references with perimeter in both the display text and URL structure.

Let's verify that all project references have been replaced in this component:

Also applies to: 53-54

✅ Verification successful

All perimeter references are correctly updated, no project references remain

The file shows consistent use of "perimeter" terminology in all relevant places - translation keys, URL paths, and data structures. No instances of "project" were found in the component.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining "project" references in the file
rg -i "project" "frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/remediation-plan/+page.svelte"

Length of output: 111

---

Script:

#!/bin/bash
# First verify file exists
fd "page.svelte" frontend/src/routes/

# If file exists, show its content
cat frontend/src/routes/\(app\)/\(internal\)/risk-assessments/\[id=uuid\]/remediation-plan/+page.svelte

# Search for any files that might contain related code
fd "remediation-plan" frontend/src/

Length of output: 8377

frontend/src/lib/utils/types.ts (2)

32-32: LGTM! URL model updated correctly.

The URL_MODEL array now includes 'perimeters' instead of 'projects', maintaining consistency with the API endpoints.

---

Line range hint 105-115: Verify interface usage across the codebase.

The Project interface has been renamed to Perimeter while maintaining the same structure. We should verify that all references to this interface have been updated.

Let's check for any remaining references to the Project interface:

✅ Verification successful

All references to the Project interface have been successfully updated

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for Project interface references in TypeScript files
rg -t ts "interface Project" 
# Search for type references to Project
rg -t ts "Project[^a-zA-Z]"

Length of output: 60

---

Script:

#!/bin/bash
# Search with various patterns that might reference the Project interface
rg -i "project" --type ts --type js -A 2 -B 2
rg ": Project" --type ts -A 2 -B 2
rg "as Project" --type ts -A 2 -B 2
rg "<Project>" --type ts -A 2 -B 2
rg "@type.*Project" --type js --type ts -A 2 -B 2

Length of output: 1422

frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte (1)

33-40: LGTM! Form component updated consistently.

The AutocompleteSelect component has been properly updated to use perimeter instead of project throughout all its properties:

• Foreign key reference
• Field name
• Cache references
• Label
• Hidden condition

Let's verify that all project references have been updated in this form:

✅ Verification successful

All "project" references successfully replaced with "perimeter"

The verification confirms that all references have been properly updated in the RiskAssessmentForm component, and no other forms in the directory contain legacy "project" references.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining "project" references in the form
rg -i "project" "frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte"
# Check if similar forms have been updated consistently
fd -t f ".*Form.svelte" "frontend/src/lib/components/Forms/ModelForm/" -x rg -l "project"

Length of output: 173

---

Script:

#!/bin/bash
# Verify file existence and path
fd "RiskAssessmentForm.svelte" frontend/

# Search for both project and perimeter with context
echo "=== Searching for 'project' references ==="
rg -i "project" frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte -C 2

echo "=== Searching for 'perimeter' references ==="
rg -i "perimeter" frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte -C 2

# Find similar forms
echo "=== Finding similar forms with 'project' references ==="
fd -t f "Form.svelte$" frontend/src/lib/components/Forms/ModelForm/ -x rg -l "project"

Length of output: 1001

frontend/tests/functional/detailed/common.test.ts (1)

14-14: LGTM! Parameter and usage updated consistently.

The refactoring from project to perimeter has been applied consistently in both the function signature and its usage.

Also applies to: 27-27

backend/iam/tests/test_user.py (2)

12-12: LGTM! Reader role permissions updated correctly.

The fixture and view permission have been correctly updated from project to perimeter.

Also applies to: 21-21

---

50-50: LGTM! Editor role permissions updated comprehensively.

All project-related permissions (view, add, change, delete) have been consistently updated to use perimeter.

Also applies to: 59-59, 69-71

frontend/src/routes/(app)/(internal)/recap/+page.svelte (2)

24-24: LGTM! Template and routing updated consistently.

The changes from projects to perimeters have been applied consistently across:

• Data iteration (data.perimeters)
• Conditional checks (perimeter.compliance_assessments)
• URL construction (/perimeters/{perimeter.id})

Also applies to: 26-26, 32-32

---

37-37: Verify data structure compatibility.

Ensure that the overallCompliance and compliance_assessments properties maintain the same structure in the perimeter model as they had in the project model.

Also applies to: 49-49

✅ Verification successful

Data structure compatibility verified successfully

The overallCompliance and compliance_assessments properties maintain consistent structure between perimeter and project models, with proper typing in the frontend and matching backend implementation. The sorting and display logic in the component correctly handles the data structure.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for type definitions and model structures
rg -A 5 "interface.*Perimeter" frontend/src/
rg -A 5 "class.*Perimeter.*Model" backend/core/models.py

Length of output: 1445

---

Script:

#!/bin/bash
# Search for RequirementAssessmentDonutItem and compliance types/models
rg -A 5 "type.*RequirementAssessmentDonutItem|interface.*RequirementAssessmentDonutItem" frontend/src/
rg -A 10 "class.*ComplianceAssessment|compliance_assessments" backend/core/models.py
rg -A 5 "overallCompliance.*values" frontend/src/

Length of output: 6003

backend/core/tests/test_helpers.py (2)

41-44: LGTM! Test cases updated correctly.

The test setup has been properly updated to use Perimeter instead of Project.

Also applies to: 51-51

🧰 Tools

🪛 Ruff (0.8.2)

41-41: Perimeter may be undefined, or defined from star imports

(F405)

---

42-42: RiskAssessment may be undefined, or defined from star imports

(F405)

---

106-109: LGTM! Duplicate test case updated consistently.

The second test case has been updated consistently with the same project to perimeter changes.

Also applies to: 116-116

🧰 Tools

🪛 Ruff (0.8.2)

106-106: Perimeter may be undefined, or defined from star imports

(F405)

---

107-107: RiskAssessment may be undefined, or defined from star imports

(F405)

backend/core/tests/test_vulnerability.py (1)

19-19: LGTM! Consistent fixture renaming.

The changes correctly reflect the transition from projects to perimeters in the test fixtures and method signatures.

Let's verify that all project references have been updated consistently:

Also applies to: 37-37, 54-54, 84-84

✅ Verification successful

Fixture renaming verification successful

The transition from projects to perimeters is complete and consistent across all test files. No legacy "project" references remain in the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining references to 'project' in test files
rg -i "project" "backend/core/tests/" --type py

Length of output: 45

---

Script:

#!/bin/bash
# First, verify the directory structure and Python files
echo "=== Checking directory structure ==="
ls -la backend/core/tests/

echo -e "\n=== Listing Python files ==="
fd -e py . backend/core/tests/

echo -e "\n=== Searching for project/perimeter references ==="
rg -i "project|perimeter" backend/core/tests/ --type py -C 2

echo -e "\n=== AST-based search for function parameters and variables ==="
ast-grep --pattern 'def $_(project$_)' backend/core/tests/
ast-grep --pattern 'def $_(perimeter$_)' backend/core/tests/

Length of output: 32453

frontend/src/routes/(app)/(internal)/analytics/+page.server.ts (1)

6-6: LGTM! Type definitions updated correctly.

The changes maintain type safety while transitioning from projects to perimeters.

Let's verify type consistency across the frontend:

Also applies to: 31-31

✅ Verification successful

Type consistency verified: Project to Perimeter migration is complete

The codebase shows consistent usage of the Perimeter type with no remaining references to the old Project type. The type system is properly maintained across the frontend.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining Project type references
rg -l "type.*Project.*" "frontend/src/" --type ts

Length of output: 49

---

Script:

#!/bin/bash
# More comprehensive search for Project-related types
ast-grep --pattern 'type Project = {
  $$$
}'

ast-grep --pattern 'interface Project {
  $$$
}'

# Search for Perimeter type usage
rg "Perimeter" "frontend/src/" --type ts -A 2

# Broader search for any remaining "Project" string
rg "Project" "frontend/src/" --type ts

Length of output: 2873

frontend/src/lib/components/SideBar/SideBar.svelte (1)

62-64: LGTM! Tour steps updated consistently.

The guided tour steps have been updated to reflect the new perimeter terminology, maintaining a consistent user experience.

Let's verify the message translations exist:

Also applies to: 71-71

✅ Verification successful

Translation keys are properly defined and implemented ✅

The tourPerimetersDescription translation key is correctly defined in both English and French language files, with proper formatting and consistent terminology.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for the new translation keys
rg "tourPerimeters.*" "frontend/src/lib/i18n/" --type ts

Length of output: 119

---

Script:

#!/bin/bash
# Find i18n-related files and directories
fd -t d "i18n"

Length of output: 14

---

Script:

#!/bin/bash
# Search for the translation method call pattern
rg "tourPerimetersDescription"

Length of output: 478

frontend/src/routes/(app)/(internal)/recap/+page.server.ts (2)

3-3: LGTM! Type definitions updated correctly.

The type imports and interface definitions have been updated to reflect the new perimeter model.

Also applies to: 27-27

---

35-39: Verify error handling for API responses.

While the API endpoint updates look correct, ensure proper error handling for failed requests.

Let's verify the API endpoint exists:

Also applies to: 42-42

✅ Verification successful

Error handling is properly implemented ✅

The code has appropriate error handling:

• Backend uses Django REST Framework's ModelViewSet with built-in error handling
• Frontend implements .catch() with proper fallback to empty array and error logging

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for the perimeters API endpoint definition
rg -A 5 "class.*PerimeterViewSet" "backend/" --type py

Length of output: 331

---

Script:

#!/bin/bash
# Check BaseModelViewSet implementation
rg -A 10 "class BaseModelViewSet" "backend/" --type py

# Check for error handling patterns around fetch calls in frontend
rg -B 2 -A 2 "catch\(" "frontend/src/routes/(app)/(internal)/recap/"

Length of output: 2796

backend/serdes/tests/test_dump.py (1)

23-23: LGTM!

The model type change from "project" to "perimeter" in the test fixture aligns with the broader refactoring effort.

frontend/src/lib/components/Forms/ModelForm/ComplianceAssessmentForm.svelte (1)

56-63: LGTM!

The AutocompleteSelect component has been correctly updated to use the perimeter model, maintaining all necessary properties and the extra_fields parameter.

backend/core/base_models.py (1)

80-81: LGTM!

The get_scope method has been correctly updated to check for the perimeter attribute instead of project, maintaining the existing scope filtering behavior.

backend/core/urls.py (1)

26-26: LGTM!

The URL pattern has been correctly updated to use the new perimeter endpoint.

🧰 Tools

🪛 Ruff (0.8.2)

26-26: PerimeterViewSet may be undefined, or defined from star imports

(F405)

frontend/src/lib/components/SideBar/navData.ts (1)

22-22: LGTM! Consistent terminology changes.

The changes correctly update all references from 'project' to 'perimeter' in both permissions and navigation items.

Also applies to: 34-34, 53-53, 55-55

frontend/src/lib/components/Forms/ModelForm/EntityAssessmentForm.svelte (1)

23-28: LGTM! Form properties correctly updated.

The AutocompleteSelect component's properties have been consistently updated from project to perimeter.

enterprise/frontend/src/lib/components/SideBar/navData.ts (1)

11-11: LGTM! Enterprise version changes align with community version.

All project-to-perimeter updates are consistent across both versions of navData.ts.

Also applies to: 23-23, 40-40, 52-52, 64-64, 83-83, 85-85

frontend/tests/utils/page-detail.ts (1)

44-44: LGTM! Test logic updated for perimeter model.

The verifyItem method correctly handles the new perimeter-based model.

Consider running the following to verify test coverage:

Also applies to: 47-47

✅ Verification successful

Verified: Changes are well-covered by existing test suite

The perimeter model is already well-tested across multiple test files:

• Utility tests: test-data.ts, test-utils.ts
• Functional tests: user-route.test.ts, common.test.ts, compliance-assessments.test.ts

The 'project' reference in e2e-tests.sh is unrelated as it's only used for Playwright configuration.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check test coverage for perimeter-related changes

# Search for test files that might need updates
rg -l 'project' frontend/tests/

Length of output: 59

---

Script:

#!/bin/bash
# Check context of 'project' usage and search for perimeter tests
echo "=== Project usage in e2e-tests.sh ==="
rg -C 3 'project' frontend/tests/e2e-tests.sh

echo -e "\n=== Existing perimeter test coverage ==="
rg -l 'perimeter' frontend/tests/

echo -e "\n=== Test file patterns ==="
fd -e ts -e js -e jsx -e tsx . frontend/tests/

Length of output: 2560

frontend/src/routes/(app)/(internal)/analytics/composer/+page.svelte (1)

127-127: LGTM! Property access updated correctly.

The change from project.str to perimeter.str aligns with the codebase refactoring from project to perimeter model.

backend/app_tests/api/test_api_perimeters.py (2)

21-75: LGTM! Comprehensive test coverage for unauthenticated scenarios.

The test class properly covers all CRUD operations for unauthenticated access:

• GET perimeters
• CREATE perimeters
• UPDATE perimeters
• DELETE perimeters

---

82-173: LGTM! Well-structured authenticated test cases with proper validation.

The test class thoroughly covers:

• CRUD operations with authentication
• Status choices validation
• Response structure verification
• Proper folder relationships

frontend/src/routes/(app)/(internal)/[model=urlmodel]/[id=uuid]/+page.server.ts (1)

76-76: LGTM! Model check updated correctly.

The condition update from 'projects' to 'perimeters' maintains the same redirect logic while aligning with the new model terminology.

frontend/tests/functional/detailed/compliance-assessments.test.ts (1)

14-14: LGTM! Test requirements updated correctly.

The test requirements array has been updated to use 'perimeters' instead of 'projects', maintaining consistency with the model refactoring while preserving the test's functionality.

frontend/tests/utils/test-data.ts (1)

6-6: LGTM! Consistent renaming from project to perimeter.

The changes systematically replace project-related keys and permissions with perimeter-related ones across all user roles, maintaining the same access control structure.

Let's verify that no project-related permissions remain:

Also applies to: 34-34, 47-47, 63-63, 81-81, 112-112, 141-141, 156-156, 174-174, 193-193, 214-214

✅ Verification successful

Verification successful: Project to perimeter migration is complete and consistent

The test data shows all permissions have been properly migrated from project to perimeter across all user roles (analyst, reader, domainManager, approver). No legacy project permissions remain in the codebase. The only project references found are unrelated to the permission system (Playwright test configuration).

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Search for any remaining project-related permissions.

# Test: Search for any remaining project-related permissions. Expect: No matches.
rg -i 'project' | rg -i 'perm'

Length of output: 131070

---

Script:

#!/bin/bash
# Search for permission-related files and check project/perimeter references

# Find permission-related files
echo "=== Permission files ==="
fd -e ts -e js perm

# Check for project references in those files
echo -e "\n=== Project references in permission files ==="
fd -e ts -e js perm --exec rg -i project {} || true

# Check for perimeter references in permission files
echo -e "\n=== Perimeter references in permission files ==="
fd -e ts -e js perm --exec rg -i perimeter {} || true

Length of output: 465

---

Script:

#!/bin/bash
# Examine test data and related files

# View test data file content
echo "=== Test data file content ==="
cat frontend/tests/utils/test-data.ts || true

# Look for permission-related types/interfaces
echo -e "\n=== Permission types and interfaces ==="
rg -t typescript "type.*Permission|interface.*Permission" frontend/

# Check for any remaining project references in frontend tests
echo -e "\n=== Project references in frontend tests ==="
rg -i project frontend/tests/

Length of output: 8592

frontend/tests/functional/user-route.test.ts (3)

128-128: LGTM! Correct perimeter reference in compliance assessment.

The path format ${folderName}/${perimeterName} is correctly structured for the perimeter reference.

---

183-183: LGTM! Correct perimeter reference in risk assessment.

The path format ${folderName}/${perimeterName} is correctly structured for the perimeter reference.

---

217-217: LGTM! Correct perimeter references in risk scenario and acceptance paths.

The path formats correctly include the perimeter in the hierarchical structure:

• Risk scenario: ${folderName}/${perimeterName}/${riskAssessmentName} - ${riskAssessmentVersion}
• Risk acceptance: ${folderName}/${perimeterName}/${riskAssessmentName} - ${riskAssessmentVersion}/${riskScenarioName}

Also applies to: 236-236

frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/edit/+page.server.ts (1)

139-139: LGTM! Correct folder reference from perimeter.

The path to get the folder ID has been correctly updated to use the perimeter object.

Let's verify the perimeter object structure:

✅ Verification successful

✓ Verified: perimeter.folder.id is correctly structured and consistently used

The change is valid as the Perimeter interface properly defines the folder property, and this structure is consistently used across both frontend and backend codebases.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the perimeter object structure in the codebase.

# Test: Search for perimeter folder references. Expect: Consistent usage of perimeter.folder.id.
ast-grep --pattern 'perimeter.folder.id'

Length of output: 724

---

Script:

#!/bin/bash
# Search for perimeter type definitions and implementations

# Look for type definitions of perimeter
ast-grep --pattern 'type Perimeter = {
  $$$
}'

# Look for interface definitions
ast-grep --pattern 'interface Perimeter {
  $$$
}'

# Search for actual implementations using perimeter.folder
rg "perimeter\.folder" -t ts -t py

Length of output: 3388

frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/+page.svelte (1)

112-112: LGTM! Correct string reference from perimeter.

The path to get the string representation has been correctly updated to use the perimeter object, maintaining the hierarchical display format: {perimeter.str}/{name} - {version}.

Let's verify the string representation format:

✅ Verification successful

Verified: Perimeter string representation is correctly used

The change from project.str to perimeter.str is correct and consistent with the codebase's standardized format for perimeter string representation (folder.name/perimeter.name). The hierarchical display format {perimeter.str}/{name} - {version} is maintained across the application.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the perimeter string representation format in the codebase.

# Test: Search for perimeter string references. Expect: Consistent usage of perimeter.str.
ast-grep --pattern 'perimeter.str'

Length of output: 34

---

Script:

#!/bin/bash
# Search for perimeter references and string representations

# Look for perimeter references in various contexts
rg "perimeter\." -A 2 -B 2

# Search for risk assessment type definitions or interfaces
rg "interface.*RiskAssessment|type.*RiskAssessment|class.*RiskAssessment" -A 5 -B 1

# Look for string representation patterns
rg "\.str\b" -A 1 -B 1

Length of output: 67384

backend/tprm/serializers.py (2)

56-56: LGTM: Field replacement looks correct.

The project field has been correctly replaced with a perimeter field using FieldsRelatedField.

---

98-98: LGTM: Audit creation logic updated correctly.

The audit creation logic has been properly updated to use the perimeter model:

• Uses perimeter for audit creation
• Correctly constructs the enclave folder name using perimeter.name

Also applies to: 106-106

backend/app_tests/api/test_api_risk_acceptances.py (2)

5-5: LGTM: Import statement updated correctly.

The Project model import has been properly replaced with Perimeter.

---

142-142: LGTM: Test data creation updated correctly.

The test data creation has been properly updated to use Perimeter instances instead of Project instances in both test methods.

Also applies to: 194-194

backend/app_tests/api/test_api_risk_assessments.py (4)

3-3: LGTM: Imports and comments updated correctly.

The Project model import and related comments have been properly replaced with Perimeter.

Also applies to: 8-8

---

30-32: LGTM: Unauthenticated test cases updated correctly.

All unauthenticated test cases have been properly updated to use Perimeter instances instead of Project instances.

Also applies to: 49-51, 65-67, 90-92

---

108-108: LGTM: Authenticated test cases updated correctly.

All authenticated test cases have been properly updated:

• Test data creation uses Perimeter
• Response validation checks for perimeter fields
• Object relationships properly maintained

Also applies to: 119-128, 141-141, 152-152, 156-161, 175-177, 190-190, 197-197, 201-206, 219-219, 228-228

---

239-239: LGTM: Status choice test updated correctly.

The TODO comment has been updated to reference Perimeter.PRJ_LC_STATUS instead of Project.PRJ_LC_STATUS.

frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/+page.svelte (1)

89-92: LGTM: UI updated correctly for perimeter display.

The component has been properly updated to display perimeter information:

• Uses correct translation key for perimeter label
• Links to the correct perimeter detail route
• Displays perimeter data consistently

frontend/src/routes/(app)/(internal)/x-rays/+page.svelte (4)

Line range hint 26-40: LGTM!

The variable name and data mapping logic correctly align with the perimeter-based structure.

---

44-47: LGTM!

The conditional check correctly uses the renamed variable.

---

47-56: LGTM!

The iteration, URL path, and display string correctly use the perimeter-based structure.

---

Line range hint 59-280: LGTM!

The template consistently uses the perimeter-based structure throughout the tab groups and conditional checks.

backend/app_tests/api/test_api_compliance_assessments.py (5)

4-4: LGTM!

The import statement correctly reflects the model change from Project to Perimeter.

---

32-34: LGTM!

The test correctly creates a Perimeter instance for the compliance assessment.

---

49-52: LGTM!

The test correctly creates a Perimeter instance for creating compliance assessments.

---

66-76: LGTM!

The test correctly creates two Perimeter instances for updating compliance assessments.

---

90-93: LGTM!

The test correctly creates a Perimeter instance for deleting compliance assessments.

frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/edit/+page.svelte (1)

95-99: LGTM!

The text label, URL path, and display string correctly reflect the transition to perimeter-based structure.

backend/ebios_rm/serializers.py (1)

30-30: LGTM!

The serializer field correctly uses the perimeter-based structure while maintaining the same field configuration.

frontend/src/lib/components/Forms/ModelForm.svelte (2)

9-9: LGTM! Import statement updated to reflect the new perimeter-centric architecture.

The import statement has been correctly updated from ProjectForm to PerimeterForm as part of the project → perimeter refactoring.

---

190-191: LGTM! Conditional rendering updated to use perimeter terminology.

The condition has been correctly updated to check for 'perimeters' instead of 'projects', maintaining consistency with the new architecture.

backend/app_tests/api/test_api_requirement_assessments.py (2)

10-10: LGTM! Import statement updated for the new model.

The import statement has been correctly updated to use Perimeter instead of Project.

---

42-42: LGTM! Test cases updated to use Perimeter model.

All test cases have been consistently updated to create and use Perimeter objects instead of Project objects, maintaining test coverage while adapting to the new architecture.

Also applies to: 80-80, 105-105, 180-180, 216-216, 221-221

backend/core/filters.py (4)

18-18: LGTM! Import statement updated for the new model.

The import statement has been correctly updated to use Perimeter instead of Project.

---

Line range hint 151-177: LGTM! Domain filter class renamed to reflect new terminology.

The ProjectsDomainFilter class has been correctly renamed to PerimetersDomainFilter while maintaining its functionality.

---

Line range hint 178-203: LGTM! Filter class renamed and placeholder text updated.

The ProjectFilter class has been correctly renamed to PerimeterFilter with appropriate updates to the placeholder text.

---

362-362: LGTM! Field renamed in ComplianceAssessmentFilter.

The field has been correctly renamed from project to perimeter in the ComplianceAssessmentFilter class.

frontend/src/lib/components/DetailView/DetailView.svelte (2)

179-181: LGTM! Condition updated to use perimeter terminology.

The condition has been correctly updated to check for 'perimeters' instead of 'projects', maintaining the same related models array.

---

186-186: LGTM! Related models array updated for folders.

The related models array for folders has been correctly updated to use 'perimeters' instead of 'projects'.

frontend/src/routes/(app)/(third-party)/compliance-assessments/[id=uuid]/+page.svelte (1)

235-235: LGTM! Filter list updated correctly.

The filter list has been updated to use 'perimeter' instead of 'project', maintaining consistency with the broader refactoring effort.

cli/clica.py (1)

162-164: LGTM! CLI commands and parameters updated consistently.

The CLI tool has been updated to use 'perimeter' terminology instead of 'project', with consistent changes across function names, parameters, variables, and dictionary keys.

Also applies to: 208-208, 218-218, 225-225, 232-232

frontend/src/routes/(app)/(internal)/analytics/+page.svelte (1)

331-334: LGTM! Analytics counter updated consistently.

The CounterCard component has been updated to use 'perimeter' terminology instead of 'project', with consistent changes to the count property, label, and navigation href.

backend/serdes/utils.py (1)

19-19: LGTM! Serialization utilities updated consistently.

The serialization utilities have been updated to use 'perimeter' terminology instead of 'project', with consistent changes across imports, serializer mappings, queries, and dictionary keys.

Also applies to: 48-48, 212-212, 432-432, 435-435, 466-466, 548-548

backend/app_tests/api/test_api_risk_scenarios.py (1)

16-16: LGTM! Comment updated to reflect new terminology.

The comment has been correctly updated from "Generic project data" to "Generic perimeter data" to maintain consistency with the new model.

backend/core/startup.py (1)

24-24: Verify permission migration completeness.

The project-to-perimeter permission migration has been applied across all role permission lists:

• READER_PERMISSIONS_LIST
• APPROVER_PERMISSIONS_LIST
• ANALYST_PERMISSIONS_LIST
• DOMAIN_MANAGER_PERMISSIONS_LIST
• ADMINISTRATOR_PERMISSIONS_LIST

Let's verify that no permissions were missed and the hierarchy is maintained:

Also applies to: 53-53, 96-96, 110-110, 127-127, 146-146, 206-206, 221-221, 239-239, 262-262, 343-346

✅ Verification successful

Permission migration successfully verified

The project-to-perimeter permission migration has been completed correctly across all role permission lists. The permission hierarchy is properly maintained, and no legacy project permissions remain in the active codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify permission migration completeness

# Check for any remaining 'project' permissions
echo "Checking for any remaining project permissions..."
rg -i 'project' backend/core/migrations/

# Verify permission hierarchy in migrations
echo "Checking permission hierarchy in migrations..."
rg -A 5 'permission_classes' backend/core/

Length of output: 5569

---

Script:

#!/bin/bash
# Check permission lists in startup.py
echo "Checking permission lists in startup.py..."
cat backend/core/startup.py

# Search for any remaining project permissions in non-migration files
echo -e "\nChecking for remaining project permissions in core..."
rg -i "project.*permission" backend/core/ --type py -g '!migrations/*'

Length of output: 18202

frontend/src/lib/utils/schemas.ts (2)

Line range hint 78-83: LGTM! PerimeterSchema correctly defined.

The schema has been properly renamed and structured with appropriate fields:

• name and description from NameDescriptionMixin
• folder as required string
• ref_id as optional nullable string
• lc_status with default value

---

99-99: Verify schema references are updated consistently.

The project to perimeter field updates have been made in:

• RiskAssessmentSchema
• ComplianceAssessmentSchema
• EntityAssessmentSchema
• SCHEMA_MAP

Let's verify all references are updated:

Also applies to: 271-271, 362-362, 494-494

✅ Verification successful

Schema references are updated consistently ✅

The migration from 'project' to 'perimeter' is complete and consistent across all schemas and their usages in the codebase. No remaining references to 'project' were found that need updating.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify schema reference updates

# Check for any remaining 'project' references in schema files
echo "Checking for remaining project references in schemas..."
rg -i 'project' frontend/src/lib/utils/

# Check for any missed schema updates
echo "Checking for any missed schema updates..."
rg -A 3 'Schema.*=.*z\.object' frontend/src/lib/utils/

Length of output: 10448

---

Script:

#!/bin/bash
# Search for SCHEMA_MAP and any remaining project/perimeter references
echo "Searching for SCHEMA_MAP..."
rg "SCHEMA_MAP" frontend/src/

echo "Checking for project/perimeter references in frontend..."
rg -i "project|perimeter" frontend/src/

Length of output: 17290

frontend/tests/utils/test-utils.ts (2)

24-24: LGTM! Test fixtures updated correctly.

The perimetersPage fixture has been properly added to replace projectsPage in:

• Fixtures type definition
• pages object construction
• page usage

Also applies to: 62-62, 81-81

---

Line range hint 371-379: Verify test data generation and page content.

The test content has been updated to use perimeter instead of project in:

• itemBuilder perimetersPage section
• complianceAssessmentsPage build
• riskAssessmentsPage build
• riskScenariosPage build
• riskAcceptancesPage build

Let's verify the test coverage:

Also applies to: 484-484, 528-528, 550-550, 577-577

✅ Verification successful

All test data sections properly updated to use perimeter instead of project

The verification confirms that all mentioned sections in test-utils.ts have been correctly updated to use perimeter-related fields and paths:

• perimetersPage build section
• complianceAssessmentsPage perimeter field
• riskAssessmentsPage perimeter field
• riskScenariosPage risk_assessment path
• riskAcceptancesPage risk_scenarios path

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify test data and page content updates

# Check for any remaining 'project' references in test files
echo "Checking for remaining project references in tests..."
rg -i 'project' frontend/tests/

# Check test patterns for perimeter-related functionality
echo "Checking test patterns for perimeter functionality..."
rg -A 3 'test.*perimeter' frontend/tests/

Length of output: 2257

---

Script:

#!/bin/bash
# Check the test data structure in the mentioned sections
echo "Checking test data structure..."
rg -A 10 'perimetersPage.*build' frontend/tests/
rg -A 10 'complianceAssessmentsPage.*build' frontend/tests/
rg -A 10 'riskAssessmentsPage.*build' frontend/tests/
rg -A 10 'riskScenariosPage.*build' frontend/tests/
rg -A 10 'riskAcceptancesPage.*build' frontend/tests/

Length of output: 1424

---

Script:

#!/bin/bash
# Examine test-utils.ts directly
echo "Checking test-utils.ts content..."
cat frontend/tests/utils/test-utils.ts

# Also check for any related test data definitions
echo -e "\nChecking for related test data definitions..."
rg -l "testObjectsData" frontend/tests/

Length of output: 18981

frontend/src/lib/utils/table.ts (3)

Line range hint 31-81: LGTM! Filter constants have been correctly renamed.

The renaming of filter constants from PROJECT to PERIMETER is consistent with the refactoring objective while maintaining the same functionality.

---

386-391: LGTM! List view fields configuration updated correctly.

The renaming of the 'projects' key to 'perimeters' in listViewFields maintains the same configuration structure while aligning with the new terminology.

---

433-437: LGTM! Assessment configurations updated consistently.

References to project have been correctly updated to perimeter in both risk and compliance assessment configurations.

Also applies to: 623-627

backend/iam/models.py (1)

161-167: LGTM! Path navigation updated correctly.

The path navigation in the get_folder method has been properly updated to use 'perimeter' instead of 'project' while maintaining the same traversal logic.

Let's verify the path navigation changes with a test:

✅ Verification successful

Path navigation changes verified successfully

The only remaining references to project.folder are in migration files which is expected and correct, as they document the historical transition. All active folder path navigation now uses 'perimeter' consistently.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that all folder path navigations have been updated from project to perimeter

# Test: Search for any remaining references to 'project' in folder path navigation
rg -i 'project.*folder' -g '!*.md' -g '!*.po'

# Test: Verify the new perimeter folder path navigation exists
rg -i 'perimeter.*folder' -g '!*.md' -g '!*.po'

Length of output: 65939

frontend/src/routes/(app)/(internal)/compliance-assessments/[id=uuid]/action-plan/+page.svelte (1)

43-47: LGTM! UI references updated correctly.

The component has been properly updated to use perimeter instead of project in messages, URLs, and data references while maintaining the same UI functionality.

backend/core/templates/snippets/ra_data.html (1)

10-10: LGTM! Project to perimeter model refactoring.

The template has been correctly updated to reference the perimeter model instead of project.

backend/core/templates/core/action_plan_pdf.html (1)

14-14: LGTM! Project to perimeter model refactoring.

The template has been correctly updated to:

1. Reference the perimeter model instead of project
2. Update the display labels from "Project" to "Perimeter"

Also applies to: 16-16

backend/core/templates/snippets/mp_data.html (1)

7-7: LGTM! Project to perimeter model refactoring.

The template has been correctly updated to:

1. Reference the perimeter model instead of project
2. Update the display labels from "Project" to "Perimeter"

Also applies to: 9-9

frontend/messages/ur.json (1)

28-28: LGTM! Keys updated while preserving user-friendly translations.

The changes consistently replace "project" with "perimeter" in the keys while retaining the familiar term "پروجیکٹ" (project) in the translations. This approach maintains a good user experience during the backend architectural transition.

Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224

frontend/messages/cs.json (1)

26-26: LGTM! Consistent key updates while maintaining user-friendly translations.

The changes systematically replace "project" with "perimeter" in the keys while preserving the familiar term "projekt" in the translations. This approach:

1. Aligns with the backend architectural changes
2. Maintains consistency with other language files
3. Ensures a smooth user experience during the transition

Also applies to: 39-39, 79-79, 117-117, 185-185, 187-187, 222-222

frontend/messages/pl.json (1)

28-28: LGTM! Keys renamed consistently while preserving user-facing terminology.

The changes in the Polish translation file correctly rename all project-related keys to use "perimeter" while maintaining "projekt" in the displayed text, ensuring a consistent internal architecture change without impacting the user experience.

Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224

frontend/messages/ro.json (1)

28-28: LGTM! Keys renamed consistently while preserving user-facing terminology.

The changes in the Romanian translation file correctly rename all project-related keys to use "perimeter" while maintaining "proiect" in the displayed text, ensuring a consistent internal architecture change without impacting the user experience.

Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224

frontend/messages/pt.json (1)

28-28: LGTM! Keys renamed consistently while preserving user-facing terminology.

The changes in the Portuguese translation file correctly rename all project-related keys to use "perimeter" while maintaining "projeto" in the displayed text, ensuring a consistent internal architecture change without impacting the user experience.

Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224

frontend/messages/it.json (1)

28-28: Verify if keeping "project" in display text is intentional.

The keys have been renamed from "project" to "perimeter" but the displayed text still shows "progetto" (project). For example:

• addPerimeter: "Aggiungi progetto"
• associatedPerimeters: "Progetti associati"
• perimeters: "Progetti"
• perimeter: "Progetto"
• myPerimeters: "I miei progetti"
• assignedPerimeters: "Assegnato al progetto{i} {number}"
• perimetersSummaryEmpty: "Riepilogo del progetto"

Is this intentional to keep the UI showing "projects" while refactoring the backend?

Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224

✅ Verification successful

Keeping "project" in display text is intentional

This appears to be a deliberate choice to maintain user-friendly terminology in the UI ("progetto") while using more technically precise terms ("perimeter") in the codebase. This pattern is consistently applied across all Italian translations, suggesting it's an intentional decision to preserve a familiar user experience.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if this pattern is consistent across the codebase

# Check for any remaining "project" references in code
echo "Checking for remaining 'project' references..."
rg -i "project" --type ts --type js --type py

# Check for new "perimeter" terminology
echo "Checking for new 'perimeter' terminology..."
rg -i "perimeter" --type ts --type js --type py

Length of output: 56460

frontend/messages/es.json (1)

28-28: Same inconsistency found in Spanish translations.

The keys have been renamed but the displayed text still shows "proyecto" (project). For example:

• addPerimeter: "Agregar proyecto"
• associatedPerimeters: "Proyectos asociados"
• perimeters: "Proyectos"
• perimeter: "Proyecto"
• myPerimeters: "Mis proyectos"
• assignedPerimeters: "Asignado a {number} proyecto{s}"
• perimetersSummaryEmpty: "Resumen de proyectos vacío"

Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224

frontend/messages/de.json (1)

28-28: Same inconsistency found in German translations.

The keys have been renamed but the displayed text still shows "Projekt" (project). For example:

• addPerimeter: "Projekt hinzufügen"
• associatedPerimeters: "Zugehörige Projekte"
• perimeters: "Projekte"
• perimeter: "Projekt"
• myPerimeters: "Meine Projekte"
• assignedPerimeters: "Zugewiesen zu {number} Projekt{en}"
• perimetersSummaryEmpty: "Projektzusammenfassung ist leer"

Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224

frontend/messages/id.json (8)

29-29: LGTM! Key renamed while preserving the translation.

The key has been updated from addProject to addPerimeter while correctly maintaining the Indonesian translation "Tambahkan proyek".

---

42-42: LGTM! Key renamed while preserving the translation.

The key has been updated from associatedProjects to associatedPerimeters while correctly maintaining the Indonesian translation "Proyek terkait".

---

84-84: LGTM! Key renamed while preserving the translation.

The key has been updated from projects to perimeters while correctly maintaining the Indonesian translation "Proyek".

---

122-122: LGTM! Key renamed while preserving the translation.

The key has been updated from project to perimeter while correctly maintaining the Indonesian translation "Proyek".

---

190-190: LGTM! Key renamed while preserving the translation.

The key has been updated from myProjects to myPerimeters while correctly maintaining the Indonesian translation "Proyek saya".

---

192-192: LGTM! Key renamed while preserving the translation.

The key has been updated from assignedProjects to assignedPerimeters while correctly maintaining the Indonesian translation "Ditugaskan ke {number} proyek{s}".

---

Line range hint 214-215: LGTM! Updated terminology in description while maintaining context.

The description has been updated to use "perimeters" instead of "projects" while maintaining the clear explanation of the composer functionality.

---

227-227: LGTM! Key renamed while preserving the translation.

The key has been updated from projectsSummaryEmpty to perimetersSummaryEmpty while correctly maintaining the Indonesian translation "Ringkasan proyek kosong".

frontend/messages/en.json (10)

28-28: LGTM! Consistent terminology update.

The key and value have been updated from project to perimeter terminology.

---

41-41: LGTM! Consistent terminology update.

The key and value have been updated from project to perimeter terminology.

---

83-83: LGTM! Consistent terminology update.

The key and value have been updated from project to perimeter terminology.

---

121-121: LGTM! Consistent terminology update.

The key and value have been updated from project to perimeter terminology.

---

189-189: LGTM! Consistent terminology update.

The key and value have been updated from project to perimeter terminology.

---

191-191: LGTM! Consistent terminology update.

The key and value have been updated from project to perimeter terminology while maintaining the dynamic placeholder format.

---

214-215: LGTM! Updated terminology in description while maintaining clarity.

The composer description has been updated to use "perimeters" instead of "projects" while maintaining clear explanation of the functionality and use cases.

---

226-226: LGTM! Consistent terminology update.

The key and value have been updated from project to perimeter terminology.

---

767-767: LGTM! Consistent terminology update.

The error message has been updated to use "perimeter" terminology.

---

1102-1103: LGTM! Updated tour descriptions with new terminology.

The tour descriptions have been updated to use "perimeter" terminology while maintaining clear guidance for users.

Reviewing files that changed from the base of the PR and between b2a775f and fbdca9b.

• backend/core/models.py (10 hunks)
• backend/core/views.py (12 hunks)
• frontend/messages/en.json (9 hunks)
• frontend/messages/fr.json (7 hunks)
• frontend/src/lib/components/Forms/ModelForm/ComplianceAssessmentForm.svelte (1 hunks)
• frontend/src/lib/utils/crud.ts (7 hunks)
• frontend/src/lib/utils/schemas.ts (5 hunks)
• frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/+page.svelte (1 hunks)

• frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/+page.svelte
• frontend/messages/fr.json
• frontend/src/lib/components/Forms/ModelForm/ComplianceAssessmentForm.svelte
• frontend/messages/en.json

• GitHub Check: enterprise-startup-functional-test (3.12)
• GitHub Check: functional-tests (3.12, chromium)
• GitHub Check: startup-docker-compose-test
• GitHub Check: enterprise-functional-tests (3.12, chromium)
• GitHub Check: enterprise-startup-docker-compose-test

frontend/src/lib/utils/schemas.ts (3)

Line range hint 78-82: LGTM! Schema definition looks correct.

The PerimeterSchema maintains the same structure as the previous ProjectSchema, ensuring type safety and data validation.

---

99-99: LGTM! Foreign key references updated correctly.

The foreign key fields in both RiskAssessmentSchema and ComplianceAssessmentSchema have been updated from 'project' to 'perimeter'.

Also applies to: 272-272

---

495-495: LGTM! Schema mapping updated consistently.

The SCHEMA_MAP entry has been updated from 'projects' to 'perimeters', maintaining consistency with the schema renaming.

frontend/src/lib/utils/crud.ts (3)

155-157: LGTM! Foreign key relationships updated correctly.

The folder relationships have been updated to reference 'perimeters' instead of 'projects'.

---

159-172: LGTM! Model mapping definition is complete.

The perimeter model mapping includes all necessary fields:

• Correct name and localization strings
• Proper foreign key relationships
• Appropriate filters

---

193-193: LGTM! Risk assessment relationships updated.

All references to 'project' in risk assessment mappings have been updated to 'perimeter'.

Also applies to: 202-202, 210-210

backend/core/models.py (6)

Line range hint 1351-1374: LGTM! Perimeter model definition is complete.

The Perimeter model maintains the same structure as the previous Project model with appropriate:

• Fields and choices
• Meta class configuration
• Verbose names

---

2053-2057: LGTM! Assessment model relationship updated.

The foreign key relationship in the Assessment model has been updated to reference the Perimeter model.

---

2096-2096: LGTM! Folder assignment logic updated.

The folder assignment in the Assessment model's save method has been updated to use perimeter.folder.

---

2157-2157: LGTM! Display methods updated.

The path display and parent reference methods have been updated to use 'perimeter' terminology.

Also applies to: 2613-2616

---

897-898: LGTM! Property references updated.

The RiskMatrix model's property has been updated to reference Perimeter objects.

---

1890-1891: LGTM! Property references updated.

The AppliedControl model's property has been updated to reference perimeters.

backend/core/views.py (3)

Line range hint 246-351: LGTM! The PerimeterViewSet implementation is well-structured.

The class provides a comprehensive set of API endpoints for managing perimeters, with proper error handling, permission checks, and documentation.

🧰 Tools

🪛 Ruff (0.8.2)

251-251: Perimeter may be undefined, or defined from star imports

(F405)

---

257-257: Perimeter may be undefined, or defined from star imports

(F405)

---

262-262: Perimeter may be undefined, or defined from star imports

(F405)

---

272-272: Perimeter may be undefined, or defined from star imports

(F405)

---

274-274: Perimeter may be undefined, or defined from star imports

(F405)

---

277-277: PerimeterReadSerializer may be undefined, or defined from star imports

(F405)

---

298-298: RiskAssessmentReadSerializer may be undefined, or defined from star imports

(F405)

---

673-674: LGTM! The filterset fields have been correctly updated.

The field names have been properly renamed from "project" to "perimeter" to reflect the model changes.

---

980-980: ⚠️ Potential issue

Add error handling for Perimeter.objects.get() call.

The current implementation assumes the Perimeter object exists, which could lead to unhandled exceptions.

Add try-except block to handle DoesNotExist:

-    _fields["perimeter"] = Perimeter.objects.get(id=data["perimeter"])
+    try:
+        _fields["perimeter"] = Perimeter.objects.get(id=data["perimeter"])
+    except Perimeter.DoesNotExist:
+        raise ValidationError({"perimeter": "Perimeter does not exist"})

Likely invalid or redundant comment.

🧰 Tools

🪛 Ruff (0.8.2)

980-980: Perimeter may be undefined, or defined from star imports

(F405)

Reviewing files that changed from the base of the PR and between fbdca9b and 4130419.

• backend/core/migrations/0051_rename_project_perimeter_alter_perimeter_options_and_more.py (1 hunks)
• backend/tprm/migrations/0004_remove_entityassessment_project_and_more.py (1 hunks)

• backend/tprm/migrations/0004_remove_entityassessment_project_and_more.py

• GitHub Check: startup-functional-test (3.12)
• GitHub Check: startup-docker-compose-test
• GitHub Check: enterprise-startup-functional-test (3.12)
• GitHub Check: functional-tests (3.12, chromium)
• GitHub Check: build (3.12)
• GitHub Check: enterprise-startup-docker-compose-test
• GitHub Check: test (3.12)
• GitHub Check: enterprise-functional-tests (3.12, chromium)

backend/core/migrations/0051_rename_project_perimeter_alter_perimeter_options_and_more.py (2)

9-13: LGTM! Dependencies are properly ordered.

The migration correctly depends on previous migrations from 'core', 'iam', and 'tprm' apps, ensuring proper execution order.

---

35-35: Consider using PROTECT instead of CASCADE for deletion.

Both ForeignKey fields use CASCADE deletion, which means deleting a Perimeter will automatically delete all associated assessments. Consider if PROTECT would be more appropriate to prevent accidental data loss.

Let's check if there are any existing deletion constraints in the codebase:

Also applies to: 40-40

✅ Verification successful

Review Verification: Consistent CASCADE Usage for Perimeter Fields

• The search results confirm that the core.perimeter foreign keys in both backend/core/migrations/0051_rename_project_perimeter_alter_perimeter_options_and_more.py and backend/tprm/migrations/0004_remove_entityassessment_project_and_more.py consistently use on_delete=django.db.models.deletion.CASCADE.
• No instance of using PROTECT for the Perimeter relation was found, indicating that the cascade behavior is applied uniformly across the codebase.
• If accidental deletion of assessments is a concern, switching to PROTECT might be worth a closer discussion; however, the current implementation appears intentional.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for existing ForeignKey deletion constraints
rg -A 2 "on_delete.*\." backend/

Length of output: 45849